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I.  INTRODUCTION 


Seaweb  is  an  undersea  network  of  acoustic  modems.  Telesonar  signaling  through 
the  ocean  medium  provides  digital  wireless  links  between  modem-equipped  network 
nodes.  The  Seaweb  network  provides  connectivity  between  undersea  assets  such  as 
submarines  and  autonomous  ASW  sensors  to  a  command  center  ashore,  permitting  target 
discrimination  and  cueing,  multi-sensor  coordination  and  tasking,  and  waterspace 
deconfliction. 

Statistical  analysis  of  a  representative  portion  of  a  Seaweb  data  set  obtained 
during  Fleet  Battle  Experiment-India  (FBE-I)  data  set  shows  the  network  is  a  reliable 
information  system  for  future  undersea  warfare. 


Figure  1.1  Seaweb  layout 
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The  FBE-India  Seaweb  network  included  twelve  nodes  at  fixed  seafloor  stations, 
two  moored  buoys,  and  a  fast  attack  submarine.  The  twelve  seafloor  nodes  included  two 
ASW  sensor  nodes  and  included  two  ASW  sensor  nodes  and  ten  repeater  nodes.  The 
buoys  were  gateway  nodes  providing  interface  between  radio  links  and  acoustic  links. 

Figure  1.1  shows  various  submarine  locations  along  with  the  links  to  adjacent 
repeater  nodes.  FBE-I  Seaweb  network  provided  the  communications  backbone  linking 
the  ashore  Anti-Submarine  Warfare  Command  Center  (ASWCC)  with  the  two  DADS 
sensor  nodes  and  a  6881  submarine  operating  at  speed  and  depth  in  the  experiment 
operating  area.  An  acoustic  network  including  10  repeater  nodes  and  2  Racom  gateway 
buoys  were  the  backbone  of  the  network. 

This  thesis  begins  with  a  review  of  the  many  constraints  and  bandwidth 
limitations  that  impair  communications  in  the  ocean  medium.  Next  is  a  description  of  the 
topology  and  hardware  factors  that  adversely  affect  the  Seaweb  network,  such  as  battery 
life  expectancy,  node  spacing,  submarine  directional  aspect,  and  submarine  depth  issues. 
Then  follows  a  general  description  of  the  link  layer  and  network  layer.  Finally, 
communication  statistics  describe  the  success  and  reliability  of  Seaweb  performance  on 
June  23,  2001,  the  most  important  day  of  the  ASW  component  of  FBE-I. 
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II.  CONSTRAINTS 


A.  UNRELIABLE  PHYSICAL  LAYER 

In  analyzing  the  performance  of  FBE-I  Seaweb,  it  is  necessary  to  consider  all  of 
the  factors  that  may  have  adversely  affected  the  flow  of  acoustic  communications  through 
the  propagation  medium  it  traveled,  the  ocean.  This  chapter  identifies  the  various 
environmental  factors  that  make  the  medium  so  unreliable. 

Testing  occurred  in  waters  80-250  meters  deep  on  the  Loma  Shelf  in  a  region 
west-southwest  of  Point  Loma,  San  Diego  and  north  of  the  US-Mexico  national  border. 
Typical  summer  conditions  existed  at  the  site  of  the  experiment.  Sound  speed  profiles 
obtained  from  conductivity-temperature-depth  (CTD)  measurements  during  the 
experiment  are  shown  in  Fig.  2.1.  [1] 


Sound  Speed  (m/il 


Figure  2.1  CTD  Measurements 

Each  line  in  the  graph  represents  a  once  daily  measurement  of  the  sound  speed 
profile  in  the  oparea.  The  four  plotted  lines  show  that  over  the  course  of  the  four-day 
experiment,  the  sound  speed  profile  was  consistent  and  varied  little.  The  graph  shows  a 
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strongly  downward-refracting  surface  layer  down  to  approximately  30  meters.  This  is 
generally  good  for  bottom-to-bottom  communications  and  is  beneficial  for  node-to-node 
communications  when  the  nodes  are  on  the  seafloor  or,  in  the  case  of  the  submarine, 
when  it  is  at  operational  depth.  The  transducers  of  the  gateway  nodes  (moored  surface 
buoys)  were  located  below  this  layer  to  reduce  the  influence  of  the  layer  on 
communications.  The  effects  of  the  strong  refracting  surface  layer  are  known  to  degrade 
communications  when  nodes  are  at  shallow  depths  above  the  layer. 

Ambient  noise  in  the  telesonar  band  is  strongly  influenced  by  local  shipping  and 
recreational  boating,  but  no  independent  noise  measurements  or  direct  observations  of 
shipping  were  attempted.  [2]  Proximity  to  the  coast  offered  increased  background  noise 
for  the  FBE-I  experiment.  Nevertheless,  the  proximity  of  FBE-I  operations  to  a 
moderately  sized  port  suggests  an  elevated  noise  floor. 

Sea  state  and  biologies  all  add  to  the  background  noise  in  the  undersea  acoustic 
medium.  When  the  submarine  was  at  periscope  depth,  the  close  proximity  to  the  surface 
most  likely  increased  the  receiver  noise  level  and  scattered  signals  sent  or  received  by  the 
submarine. 

Environmental  parameters  such  as  local  air  temperature,  water  temperature,  depth, 
wind  speed  and  direction,  sound-speed  profiles,  and  sea  state  were  measured  and 
recorded.  These  conditions  could  have  affected  the  performance  of  the  network,  but  a 
detailed  study  has  not  been  conducted  to  identify  specific  relationships  between 
performance  and  these  factors.  Other  factors  that  were  not  quantified  are:  biologies, 
rainfall,  amount  of  local  shipping,  recreational  boating  throughout  the  area,  and  other 
human  activities  in  the  surrounding  area. 

Attenuation  and  multipath  are  other  examples  of  the  constraints  that  are  present  in 
the  medium.  Attenuation  is  the  reduction  of  signal  strength  at  the  receiver  as  a  result  of 
traveling  through  the  medium.  If  the  signal  attenuates  too  much,  it  becomes  lost  in  the 
noise  background  and  it  becomes  unintelligible.  Multipath  occurs  when  a  signal  takes 
different  paths  while  propagating  from  a  source  to  a  destination  node.  A  portion  of  the 
signal  may  travel  directly  to  the  destination,  and  others  may  bounce  from  the  surface  or 
bottom  before  reaching  the  destination.  As  a  result,  some  of  the  signal  will  experience 
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delay  from  the  longer  paths  to  the  receiver.  Sound  propagation  through  the  ocean  suffers 
from  distortion  and  dispersion  from  multipath,  and  this  effect  is  highly  variable  in 
shallow  littoral  waters  such  as  those  used  for  FBE-I. 

B.  BANDWIDTH  LIMITATIONS 

Bandwidth  is  the  amount  of  data  that  can  be  transmitted  per  unit  of  time.  The 
FBE-I  Seaweb  network  used  a  physical  layer  having  a  300  bit/s  information  rate.  Seaweb 
is  constrained  to  a  specific  amount  of  the  acoustic  spectrum  due  to  the  low-pass  filter 
property  of  the  ocean  and  to  the  transducer  transmit  response.  The  FBE-I  Seaweb 
operating  frequencies  occupied  the  9-14  KHz  acoustic  band.  The  network  is  matched  to 
this  limitation  by  using  formatted,  brief  messages  that  include  only  required  and 
necessary  information. 


C.  LATENCY 

At  normal  communication  ranges  of  2-4  km,  it  takes  a  few  seconds  for  a  signal  to 
propagate  from  transmitter  to  receiver  due  to  the  approximately  1500  m/s  speed  of  sound 
in  water. 

D.  DIRECTIONAL  ISSUE  WITH  SUBMARINE 

The  submarine  transducer  used  for  acoustic  communications  with  the  Seaweb 
network  was  located  in  the  bow.  Communications  to  Seaweb  nodes  located  abeam  or 
astern  suffered  from  reduced  transducer  directivity  but  were  nevertheless  successful  at 
ranges  within  1  kilometer.  Communications  in  the  rear  quarter  were  unsuccessful  on 
some  occasions  because  of  complete  baffling  of  the  bow  HF  transducers  by  the  hull.  [2] 


E.  BATTERY  LIFE 

The  repeaters  and  the  gateways  are  autonomous  devices  operating  on  battery 
power  with  finite  endurance.  However,  it  is  possible  to  service  the  network  components 
on  a  regular  basis  to  replace  depleted  batteries.  To  anticipate  potential  outages  the 
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Seaweb  server  operator  can  query  an  individual  node  to  determine  its  battery  status. 
Also,  the  Seaweb  server  operator  can  issue  commands  to  re-route  traffic  around  weak 
network  nodes.  During  the  four  continuous  days  of  Seaweb  operations  at  FBE-I,  battery 
power  was  not  an  issue. 
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III.  SEAWEB 


A.  LINK  LAYER 

Seaweb  is  an  undersea  wireless  network  fundamentally  based  upon  the  telesonar 
link  protocol.  This  protocol  involves  a  handshaking  process  compatible  with  half-duplex 
signaling.  In  the  link  protocol  concept,  the  initiating  node  transmits  a  request  waveform 
with  a  spread-spectrum  pattern  uniquely  associated  with  the  intended  receiver. 

The  receiver  node  detects  the  request,  and  awakens  from  a  low-power  sleep  state. 
Further  processing  of  the  request  signal  provides  an  estimate  of  the  channel  scattering 
function  and  signal  excess.  The  node  then  acknowledges  receipt  with  an  acoustic  reply. 
This  response  specifies  appropriate  modulation  parameters  for  the  ensuing  data  packets, 
based  upon  the  prevailing  channel  conditions.  Following  this  handshake,  the  initiating 
node  transmits  the  data  packet(s)  with  optimized  bit-rate,  modulation,  coding,  and  source 
level. 

Seaweb  quality  of  service  is  limited  by  low-bandwidth,  half-duplex,  and  high- 
latency  telesonar  links.  Poor  propagation  conditions  or  elevated  noise  levels  contribute  to 
occasional  network  outages  and  corrupted  data  packets.  To  minimize  data  loss,  a 
medium-access-control  (MAC)  handshaking  method  illustrated  in  Figure  3.1  has  been 
adopted.  Half-duplex  handshaking  asynchronously  establishes  adaptive  telesonar  links 
[3], 

The  initiating  node  transmits  a  Request  To  Send  (RTS)  utility  packet  with  a 
spread-spectrum  pattern  uniquely  addressing  the  intended  receiver.  Alternatively,  the 
initiating  node  may  transmit  a  universal  code  for  broadcasting  or  when  establishing  a  link 
with  an  unidentified  node.  The  addressed  node  detects  the  request  and  awakens  from  an 
energy-conserving  state  to  demodulate  the  signal  [3], 

The  RTS  signal  is  processed  to  provide  an  estimate  of  the  channel  scattering 
function  and  signal  excess.  The  addressed  node  then  acknowledges  receipt  with  a  utility 
packet  referred  to  as  Clear-To-Send  (CTS).  This  CTS  reply  specifies  appropriate 
modulation  parameters  for  the  ensuing  message  packets  based  on  the  measured  channel 
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characteristics.  Following  the  RTS/CTS  handshake,  the  initiating  node  transmits  the 
DATA  packet(s)  at  a  nearly  optimal  bit-rate,  modulation,  coding,  and  source  level.  The 


Figure  3.1  Two  Node  State  Diagram 

initiating  node  then  waits  a  predefined  time  before  it  is  able  to  accept  additional  incoming 
RTS  requests.  If  the  DATA  packet  is  decoded  at  the  addressed  node  and  found  to  have 
unrecoverable  bit  errors,  an  Automatic-Repeat-Request  (ARQ)  utility  packet  is  sent  to  the 
initiating  node.  Upon  receipt  of  the  ARQ,  the  initiating  node  repeats  the  DATA  packet 
transmission.  The  maximum  number  of  ARQ  requests  is  a  programmable  function  of  the 
telesonar  modem  and  is  controlled  by  the  Seaweb  server  operator.  For  this  experiment, 
the  maximum  number  of  ARQ  requests  was  set  at  three.  [1] 

The  focus  of  this  thesis  is  to  analyze  one  day  of  Seaweb  network  traffic  from 
FBE-I  to  determine  the  RTS/CTS/DATA/ARQ  (link  layer)  handshaking  protocol 
effectiveness.  The  purpose  of  conducting  this  analysis  is  to  evaluate  the  benefits  of  using 
this  handshaking  protocol  and  to  quantify  the  performance  of  the  Seaweb  network  during 
FBE-I. 


B.  NETWORK  LAYER 

Data  structures  residing  in  the  modems  define  the  network  routing  for 
communications  traffic.  These  routing  tables  are  initialized  for  each  modem  by  the 


8 


network  administrator  prior  to  deployment  of  the  network  by  setting  the  values  of  certain 
S-registers.  The  values  correspond  to  the  node  addresses  of  neighbor  nodes  that 
correspond  to  a  predetermined  routing  topology.  The  S-register  addresses  that  make  up 
the  routing  table  are  40-60  in  hexadecimal.  S-register  41  corresponds  to  a  receiving 
modem  node  address  of  ‘  1  42  to  a  node  address  of  ‘2’,  and  so  on. 

The  function  of  the  routing  table  can  be  explained  with  the  following  example. 
When  a  modem  receives  a  message,  the  message  header  tells  the  modem  the  final 
destination  address  for  that  message.  The  modem  looks  up  this  address  in  its  routing 
table  to  determine  which  modem  is  to  receive  the  message  next  in  the  route  to  the  final 
destination.  For  example,  say  we  have  a  network  made  up  of  three  nodes  and  the  routing 
is  designed  as  a  simple  linear  route.  In  the  following  example,  node  1  is  the  “source” 
address  and  node  3  is  the  “destination”  address. 

1-2-3 

The  routing  tables  for  the  modems  would  be  as  follows: 

12  3 

541  1  1  2 

542  2  2  2 

543  2  3  3 

Each  column  is  the  routing  table  for  the  modem  address  designated  by  the  column 
header.  A  message  is  sent  from  ‘1’  to  ‘3’.  ‘1’  knows  that  ‘3’  is  the  final  destination  for 
the  message.  It  looks  in  its  routing  table  to  see  that  in  order  to  send  a  message  to  the  final 
destination  of  ‘3’,  it  must  send  the  message  to  ‘2’.  When  ‘2’  receives  the  message,  the 
message  header  tells  it  that  ‘3’  is  the  final  destination,  so  ‘2’  looks  in  its  routing  table  to 
see  that  ‘3’  is  the  next  modem  to  send  the  message  to.  ‘3’  receives  the  message  and  the 
header  tells  it  that  this  is  the  final  destination  for  the  message  and  ‘3’  processes  the 
message.  ‘2’  acted  as  a  simple  repeater  of  the  message  and  did  not  process  its  contents. 
The  example  routing  table  also  permits  source  node  ‘3’  to  network  data  to  destination 
node  ‘1’  via  repeater  node  ‘2’. 
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Through  the  Seaweb  server,  the  network  administrator  can  remotely  reprogram 
the  routing  tables  of  a  deployed  network  [6].  The  distributed  routing  architecture 
anticipates  the  future  implementation  of  an  autonomously  self-organizing  and  self- 
healing  Seaweb  network  layer  [7], 
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IV.  FBE-I  SEAWEB  NETWORK 


A.  MOTIVATION 

Future  ASW  forces  will  rely  heavily  upon  unmanned  undersea  sensors  and 
vehicles.  The  tactical  application  of  these  new  capabilities  is  dependent  on  the  data 
connectivity  through  the  water  and  through  the  sea/air  interface.  The  ASW 
experimentation  for  FBE-I  focused  on  undersea  acoustic  network  connectivity  between 
the  acoustic  and  radio  frequency  (RF)  regimes,  while  incorporating  existing  ASW  data 
formats  (e.g.,  GCCS-M)  into  a  theater  tactical  capability  [4,  6], 

FBE-I  was  the  ninth  in  a  series  of  CNO  sponsored  experiments  coordinated  by  the 
Navy  Warfare  Development  Command  (NWDC).  The  NWDC  Mission  is  to 
“Operationally  examine  innovative  concepts  and  emerging  technologies  to  identify 
advanced  warfighting  capabilities  for  further  development  and  rapid  transition  to  the 
fleet.”  FBE-I  was  conducted  in  the  Third  Fleet  Area  of  Operations  from  18  June  through 
28  June  2001.  The  dates  for  the  Seaweb  operation  were;  20-23  June  2001.  The  first  two 
days  (20-21  June)  were  focused  on  a  wide  variety  of  data  transmissions  to  see  what  data, 
and  in  what  format,  would  have  operational  utility  for  an  undersea  communications 
system.  Note:  On  the  second  experiment  day  (21  June),  the  experiment  was  temporarily 
suspended  by  the  FCC,  due  to  a  possible  military-civilian  RF  frequency  spectrum 
conflict. 

The  last  two  days  (22-23  June)  comprised  the  tactical  engagement  scenarios, 
which  examined  the  use  of  the  undersea  network  for  such  missions  as  ASW  target 
localization  through  cooperative  engagements  by  maritime  patrol  aircraft  and  friendly 
submarine  at  depth  against  a  hostile  submarine. 
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Figure  4.1  FBE-I  Seaweb  Deployment  Topology 
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B.  FOCUS  FOR  DATA  ANALYSIS 


As  previously  stated,  the  first  day  of  the  experiment  was  mostly  set  up,  testing, 
and  determining  message  text  and  formats  to  be  used  during  the  experiment.  The  second 
day  of  the  experiment  was  suspended  due  to  RF  problems.  Considering  the  extensive 
time  required  creating  the  necessary  spreadsheet  by  manually  translating  the  server  logs 
the  fourth  day  (23  June  2001)  became  the  focus  for  this  analysis.  Even  though  the 
network  consisted  of  2  gateways  to  access  the  network,  this  analysis  is  focused  only  on 
the  “Delta”  Radio/ Acoustic  communications  (Racom)  gateway  node  because  the  “Echo” 
gateway  was  used  primarily  for  the  DADS  Node’s  traffic.  Due  to  DADS  requirements, 
the  “Echo”  gateway  was  not  configured  to  be  used  for  network  analysis.  Therefore,  the 
data  analyzed  is  only  the  acoustic  Seaweb  network  traffic  that  was  sent,  received,  or 
overheard  by  the  “Delta”  Racom  buoy  gateway  node  and  the  submarine  passive  Seaweb 
server. 


C.  OPERATOR  INVOLVEMENT  AND  LOCATION 


NAME 

ORGANIZATION 

JOB  TITLE/RESPONSIBILITY 

Joe  Rice 

SPAWARSYSCEN  San  Diego 

TELESONAR  Project  Manager 

Chris  Fletcher 

SPAWARSYSCEN  San  Diego 

Seaweb  Server  Operator 

Bob  Creber 

SPAWARSYSCEN  San  Diego 

Seaweb  server  operator 

Jim  Hardiman 

Benthos,  Inc. 

Representative-installation/ 

operations 

Stephen  Pelstring 

NWDC  San  Diego 

Undersea  Retired  Navy 

Table  1.  ASW  Command  Center  and  Submarine  Manning  Table 
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1. 


Seaweb  Server 


A  Seaweb  server  resided  at  the  ASWCC  and  onboard  the  submarine.  The  Seaweb 
server  provides  network  administration  using  a  graphical  user  interface.  Network 
routing,  health,  sensor  and  instrument  control,  and  data  archiving  are  controlled  by  the 
Seaweb  server  [8]. 

2.  Repeaters/Telesonar  Modem 

The  telesonar  modems  are  Benthos  model  ATM885  subsea  modems.  The 
frequency  range  of  the  communication  signals  is  9-14  KHz.  Seaweb  repeater  nodes  were 
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Figure  4.2  Deployed  Telesonar  Repeater 
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Deployed,  as  shown.  The  rig  freefalls  to  the  bottom  when  dropped  from  a  small  surface 
vessel. 

At  the  completion  of  the  mission,  the  acoustic  release  separates  the  rig  from  the 
anchor  block  and  everything  except  the  block  rises  to  the  surface  for  recovery.  Since 
these  modems  are  located  on  the  seafloor  and  extend  to  only  about  8  meters  up,  they  do 
not  pose  a  threat  to  submarine  safety. 

3.  Racom  Gateway  Buoy 

The  Racom  gateway  buoy  is  the  interface  between  the  undersea  network  and  the 
Seaweb  Server.  The  Racom  can  be  configured  with  one  of  many  communication  options. 


Figure  4.3  Racom  Gateway  Buoy 
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Communication  to  the  Seaweb  Server  can  be  via  freewave  packet  radio  modem,  Iridium 
satellite  modem,  or  CDPD  cell  phone  modem.  The  Racom  gateways  used  during  FBE-I 
were  configured  with  the  freewave  packet  radios.  The  Racom  gateways  are  designed  and 
constructed  by  SPAWAR  Systems  Center  San  Diego. 


Typically,  the  transducer  is  located  at  a  depth  of  about  25  meters  below  the  Racom 
gateway.  Since  the  Racom  gateway  is  a  moored  instrument,  care  must  be  taken  when 
determining  the  deployment  position.  Since  there  was  a  submarine  involved  in  FBE-I, 
the  Racoms  were  required  to  be  moored  at  a  considerable  distance  from  the  submarine 
operations  area  for  submarine  safety.  The  Seaweb  network  topology  was  carefully 
designed  around  submarine  safety. 
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D.  SUBMARINE  POSITION  AS  FUNCTION  OF  TIME 


In  order  to  assess  possible  directional  issues  with  the  submarine  transducer,  a 
chart  was  produced  depicting  the  location  and  depth  of  the  submarine  at  ten  minute 
intervals  and  the  locations  of  fixed  nodes.  This  chart  was  produced  by  plotting  the 
information  provided  from  the  FBE-I  Ring  Laser  Guided  Navigation  (RLGN)  data;  Zulu 
time,  Latitude,  Longitude,  Heading,  Depth,  and  Speed. 

This  chart  was  extremely  valuable  in  identifying  specific  examples  of  problem 
data  packets  and  categorizing  unsuccessful  data  packets.  By  comparing  the  timestamp  of 
the  data  packet  in  the  data  set  to  Figure  4.5  it  was  easy  to  determine  if  the  submarine 
heading  was  facing  away  from  the  intended  recipient  node.  However,  on  some 
occasions,  the  data  packet  was  successful  and  was  received  by  the  intended  node,  even 
though  the  intended  node  was  abeam  or  aft  the  beam  of  the  submarine.  These  packets 
succeeded  because  of  close  proximity  of  the  submarine  to  the  intended  node  recipient. 

In  the  FBE-I  Seaweb  design,  the  submarine  cells  (S  nodes)  were  regions 
associated  with  repeater  nodes.  When  the  submarine  was  within  one  of  these  cells,  it 
would  assume  the  S  address  as  its  own.  Thus,  the  submarine  would  take  on  a  different 
identity  as  it  moved  from  cell  to  cell.  In  2001,  Seaweb  did  not  yet  support  mobile 
addressing,  and  the  S  addresses  provided  an  effective  workaround. 
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SUBMARINE  LATITUDE  vs  TIME  OF  DAY 


Q. 

LU 

D 

LU 


DC 

< 


CQ 

Z> 

CO 


SUB_LAT 

- R1_LAT 

- R2_LAT 

R8_LAT 

-  ■D3_LAT 

R9_LAT 

- R4_LAT 

RA_LAT 
-  -  D5LAT 

- RB_LAT 

- R6_LAT 

- R7_LAT 

DEPTH 


TIME  OF  DAY 


Figure  4.5  Sub  Latitude/Depth/Time  Chart 


Using  the  time  stamps  of  the  problem  packets  available  in  the  data  set,  a 
comparison  could  be  made  to  determine  where  the  submarine  was  at  any  particular  time 
of  transmission,  and  which  node  was  its  intended  recipient.  This  comparison  ensured  that 
a  fairly  accurate  determination  of  whether  or  not  the  transmission  could  be  received  by 
the  intended  node  recipient. 
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V.  FBE-I  NETWORK  LAYER  PERFORMANCE 


A.  NODE  USAGE 

Source  addresses  are  nodes  that  initiate  sending  traffic  or  data  packets  through  the 
network.  G  denotes  a  Gateway  node,  D  a  DADs  node,  and  S  a  Submarine  cell.  The 
primary  source  addresses  were  nodes  GD,  GE,  D3,  D5,  and  SI  1-S17. 

Destination  addresses  are  nodes  that  are  the  final  recipient  of  data  packets.  The  primary 
destination  addresses  are  once  again  GD,  GE,  D3,  D5,  and  SI  1-S17. 
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Figure  5.1  DATA  Packet  Source  &  Destination  Nodes  (Network  Layer) 


Figure  5.1  categorizes  the  network  layer  source  and  destination  node  addresses  for 
the  263  data  packets  as  they  were  transmitted  through  the  network  on  June  23.  This 
distribution  of  source  and  destination  network  nodes  was  expected  since  nodes  GD  and 
GE  were  the  Racom  buoy  gateways  that  initiated  a  majority  of  the  traffic  originating  at 
and  destined  for  the  ASWCC.  Nodes  S12,  S14,  and  S16  were  the  submarine  designated 
operating  areas,  and  were  the  submarine  cells  that  were  mostly  utilized.  Cells  Sll  and 
S17  were  located  at  the  turn  around  for  the  North  and  South  runs;  therefore,  these 
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addesses  were  not  used  as  often.  The  submarine  was,  by  design,  the  intended  recipient 
for  much  of  the  experimental  traffic.  Nodes  D3  and  D5  were  the  DADs  sensor  nodes  that 
initiated  contact  reports  to  be  transmitted  to  the  ASWCC  for  further  dissemination  via  the 
D  and  E  gateways.  The  various  other  individual  R  node  usages  were  most  likely  the 
nodes  receiving  and  responding  to  health/status  requests  from  the  ASWCC. 

B.  ROUTING  TABLES 


Each  column  is  the  routing  table  for  the  modem  at  the  designated  node  address. 
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Table  2.  Routing  Tables 

Note  that  these  tables  can  be  modified  via  acoustic  command  following 
deployment  of  the  network.  For  example,  on  the  last  day  of  the  FBE-I  test,  node  RC  was 
taken  out  of  most  routes  to  reduce  latency.  The  routing  tables  for  all  modems  that  used 
‘C’  in  their  route  were  acoustically  reprogrammed  to  replace  ‘C’  to  either  ‘9’  or  ‘A’  for 
outgoing  routes  and  either  ‘D’  or  ‘E’  for  incoming  routes. 

The  network  identifies  four  types  of  packets.  During  the  experiment  of  23  June 
2001,  the  network  trafficked  a  total  of  2097  packets  throughout  the  system.  These  2097 
packets  were  categorized  by  the  traffic  sent  from  source  to  destination  node  and  mapped 
(via)  their  respective  routings  throughout  the  Seaweb  network  nodes.  Each  of  these  2097 
elements  produced  a  total  of  263  serials. 

A  serial  is  described  as  the  source  to  destination  identity  of  a  DATA  packet.  Each 
time  the  DATA  packet  was  sent  via  the  prescribed  routing  table,  it  took  the  form  of  RTS- 
CTS-DATA.  Associated  with  the  DATA  packet  is  the  size  of  the  packet.  A  link  is 
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described  as  node-to-node  transfer  of  information.  Analysis  shows  that  there  were  263 
serials  at  the  network  layer,  and  525  links  at  the  link  layer. 


C.  PACKET  TRAFFIC 

Figure  5.2  is  a  histogram  of  the  packet  traffic  by  packet  type  throughout  the 
network.  The  breakdown  of  the  2097  packets  are  as  follows:  there  were  774  RTS 
packets,  587  CTS  packets,  596  DATA  packets,  69  ARQ  packets,  and  71  UNK  packets 


RTS  CTS  DATA  ARQ  BLANK 

Figure  5.2  Distribution  of  Packets  Transmitted,  by  Packet  Type 


throughout  the  network.  The  network  propagates  RTS  retries  (Up  to  five)  after  a  certain 
lapse  timeframe  to  ensure  the  data  can  be  trafficked  throughout  the  network  to  its 
intended  recipients.  This  explains  the  large  number  of  RTS  transmissions  (RTS  retries) 
in  the  histogram.  UNK’S  represent  an  inability  to  identify  the  type  of  transmission 
through  the  analysis  means  available.  Transmissions  occurred,  but  the  monitoring 
gateway  could  not  identify  the  specific  packet  type.  Keep  in  mind  that  the  sequencing  of 
data  packets  is  RTS-CTS-DATA,  then  ARQ-DATA  when  necessary  (up  to  three  ARQ’s). 
Note:  Notice  the  elemental  counts  do  not  match.  This  indicates  that  some  data  packets 
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made  their  way  through  the  network,  even  though  the  monitoring  system  did  not  properly 
log  the  network  activity. 

D.  NODE  USAGE 

Figure  5.3  tallies  the  link  layer  transmitter  and  receiver  node  usage  for  the  2,097 
DATA  packets  occurring  in  the  network.  As  will  be  discussed  in  Figure  5.6,  the  number 
of  links  per  data  packet  was  grouped  into  the  network  layer  statistics.  Figure  5.3 


□  X  NODE  ■  R  NODE 

Error! 

Figure  5.3  Node  Usage  (Link  Layer) 


demonstrates  the  node  usage  for  all  individual  links  from  node  to  node  as  each  DATA 
packet  moved  from  source  to  destination.  While  a  packet  was  transmitted  from  source  to 
destination,  it  may  have  traveled  from  Gateway  Delta  (GD)  to  Sub  cell  (S14).  To 
complete  the  transmission  it  would  have  traveled  from  GD  to  Repeater  Node  (R9),  R9  to 
R4,  then  finally  from  R4  to  S14. 

Source  (GD)  to  Destination  (S14)  -  One  Serial  Data  packet 
GD  to  R9  -  1st  Link 
R9  to  R4  -  2nd  Link 
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R4  to  S14  -  3rd  Link 


This  example  DATA  packet  transmission  is  accounted  for  in  the  GD  transmit 
column,  R9  Receive  column,  R9  transmit  column,  and  R4  receive  column,  R4  transmit 
column,  and  the  S14  receive  column  adding  one  to  the  total  of  each  column  in  Figure  5.3 
histogram. 

The  histogram  accounts  for  the  total  number  of  links  that  all  DATA  packets 
encountered  while  traveling  through  the  network  to  get  from  source  to  destination.  Note 
the  D4  and  F9  node  annotations.  These  nodes  were  recorded  as  a  result  of  information 
contained  in  the  source  data.  These  nodes  did  not  exist  within  the  network.  The 
assumption  is  those  nodes  should  have  been  more  aptly  reported  as  nodes  D  and  E 
respectively. 


E.  DATA  PACKET  OUTCOME 


Figure  5.4  DATA  Packet  Fates 


Figure  5.4  is  a  histogram  of  the  fate  of  DATA  packets  transmissions  throughout 

the  network.  There  were  a  total  of  263  DATA  packets  offered  to  the  Seaweb  network  on 
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23  Jun  2001.  This  is  the  sequencing  of  DATA  transmissions  throughout  the  network 
from  source  to  destination  node  inclusive  of  all  the  intermittent  nodes  along  the 
prescribed  path  of  the  transmission.  The  breakdown  of  the  263  serial  packet 
transmissions  are  as  follows:  there  were  171  GOOD  transmissions,  10  Depth  Problem 
(DP)  transmissions,  24  Submarine  Aspect  (SA)  transmissions,  15  Error  in  Header  (EH) 
transmissions,  14  Collision  (CL)  transmissions,  and  29  Fractional  Packets  (FP)  data 
packet  transmissions  throughout  the  network.  GOOD  is  defined  as  the  successful 
transmission  of  DATA  packets  from  source  to  destination  node.  DP  is  defined  as  a 
problem  encountered  by  the  unsuccessful  transmission  of  a  data  packet  from  source  to 
destination  node  while  the  submarine  was  in  a  depth  transition.  SA  is  defined  as  a 
problem  encountered  by  the  unsuccessful  transmission  of  a  data  packet  from  source  to 
destination  node  while  the  submarine  was  attempting  to  transmit  to  a  node  located  aft  of 
its  beam.  EH  is  defined  as  a  problem  encountered  by  the  unsuccessful  transmission  of  a 
data  packet  from  source  to  destination  node  with  missing  elements  of  the  data  packet.  CL 
is  defined  as  a  problem  encountered  by  the  unsuccessful  transmission  of  a  data  packet 
from  source  to  destination  node  interrupted  by  another  transmission  occurring  at  the  same 
time  at  a  particular  node  in  the  serial.  FP  is  defined  as  a  problem  encountered  by  the 
interruption  of  a  successful  transmission  of  a  data  packet  from  source  to  destination,  but 
the  data  packet  successfully  made  it  to  the  intended  node  recipient.  An  administrative 
scrub  of  the  submarine  data  log  was  needed  to  verify  the  data  packet  success.  Because 
the  submarine  log  could  only  identify  in  ZULU  time,  a  true  latency  for  this  data  packet 
could  not  be  computed.  Both  the  DP  and  SA  problems  encountered  appear  to  be 
influenced  by  human  error,  ft  appears  that  the  error  was  either  by  the  operator 
transmitting  to  a  node  physically  located  aft  of  its  beam  or  the  cone  angle  of  the  sonar 
propagation  misaligned  with  the  nodes  ability  to  capture  the  transmission  of  the 
information  via  the  medium  (ocean).  In  reviewing  this  phenomenon,  the  need  for 
incorporating  the  submarines  actual  location  with  respect  to  the  timing  of  nodal  traffic  is 
necessary,  as  considered  in  Section  IV(D),  Figure  4.5.  Investigation  was  necessary  to 
verify  potential  (SA/DP)  problems  encountered  in  the  network. 
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F.  DATA  PACKET  SIZE 

Figure  5.5  categorizes  DATA  packet  size.  DATA  packet  size  was  categorized  in 
50  byte  intervals.  The  distribution  of  the  frequency  of  all  263  packet  sizes  is  accounted 
for  in  Figure  5.5.  There  were  221  data  packets  with  byte  size  <500.  The  remaining  42 
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DATA  packets  were  Unknown  (UNK).  The  DATA  packets  of  byte  size  UNK  were  those 
DATA  packets  successfully  transmitted,  but  did  not  have  any  information  about  the 
actual  byte  size  field  annotated  in  the  original  data  set.  Of  the  42  UNK  DATA  packets  2 
were  due  to  EH  problems,  3  to  CL  problems,  4  to  FP  problems,  2  to  DP  problems,  3  to 
SA  problems  and  23  to  UNK  transmission  time  stamp.  In  some  cases  the  element  type 
was  inferred  based  on  previous  transmissions  in  the  network. 
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Figure  5.6  Number  Links  per  Packet  (Network  Layer) 
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Figure  5.6  demonstrates  the  network  layer  number  of  links  per  data  packet  as  they 
were  transmitted  through  the  network.  While  a  packet  was  transmitted  from  source  to 
destination,  it  may  have  traveled  from  Gateway  Delta  (GD)  to  Sub  OP  AREA  (S14).  To 
complete  the  transmission  it  would  have  traveled  from  GD  to  Repeater  Node  (R9),  R9  to 
R4,  then  finally  from  R4  to  SI 4. 

Source  (GD)  to  Destination  (S14)  -  One  Serial  Data  packet 
GD  to  R9  -  1st  Link 
R9  to  R4  -  2nd  Link 
R4  to  S14  -  3rd  Link 

This  example  data  packet  transmission  would  have  been  accounted  for  in  the 
LINKS  (3)  category  of  the  Figure  5.6  histogram. 

The  histogram  tallies  the  total  number  of  links  each  DATA  packet  traveled  to  get 
from  source  to  destination. 
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Table  3.  LINK  (0)  Explanation 


Explanation  for  LINKS(O):  Previous  table  describes  problem  area. 
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H.  PACKET  LATENCY 


Figure  5.7  groups  the  Data  packet  latency  (in  Seconds)  that  each  transmission 
experienced  traveling  through  the  network.  The  histogram  accounts  for  the  time  one  data 
packet  serial  takes  (in  seconds)  to  get  from  source  to  destination  node.  Data  packet 
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Figure  5.7  Latency  (Network  Layer) 


length  was  categorized  in  30  second  intervals.  This  was  the  total  accounting  of  all  171 
GOOD  data  packets. 

Note:  Reason  for  long  latency  (151-180)  -  Packet  #232  was  a  depth  issue  that  the 
data  packet  survived  after  a  collision  with  data  packet  #233. 
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VI.  FBE-INDIA  LINK-LAYER  PERFORMANCE 


A.  RTS  FREQUENCY 

Figure  6. 1  demonstrates  the  link  layer  RTS  re-tries  that  occurred  during  FBE-I,  23 
June  2001.  An  RTS  transmission  is  sent  by  the  transmitter  node  to  the  intended  receiver 
node.  The  RTS  transmission  starts  the  handshaking  process  at  the  beginning  of  each  link 


NUMBER  OF  RTSs 

Figure  6.1  RTS  Usage  (Link  Layer) 


until  the  data  packet  is  received  at  the  intended  destination  node.  The  transmitter  node 
issue  an  RTS  retry  after  a  certain  lapsed  time-frame  to  ensure  the  data  can  be  trafficked 
throughout  the  network  to  its  intended  recipients. 

During  FBE-I,  a  maximum  number  of  RTS  transmission  attempts  were  set  at  5. 
Once  5  attempts  were  completed,  the  data  packet  was  programmed  to  cease  transmission, 
and  the  DATA  packet  would  be  dropped.  The  figure  shows  that  the  majority  of  the  RTS 
transmissions  were  successful  on  the  first  attempt  (424  out  of  774).  54  after  the  two,  14 
after  three,  10  after  4,  and  6  were  successful  after  5  attempts. 
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RTS(1  attempt)  =  424 
RTS(2  attempts)  =  54 
RTS(3  attempts)  =  14 
RTS(4  attempts)  =  10 
RTS(5  attempts)  =  6 

Total:  424  x  1  +  54  x2  +  14x3  +  10x4  +  6x5  = 
424+  108  +  42  +  40  +  30  =  644 

644  out  of  774  were  successful  within  the  allotted  5  RTS  retry  attempts. 


RTS  Count  Pckt#  Link#  Problem  Area 


6  151  288  DP 

6  152  289  DP 

6  153  290  DP 


8  55  110  CL 

8  104  199  R-RTS 

8  115  220  DP 

8  243  486  CL 


14  106  206  DP 


Table  4.  RTS>5  Overage  Count  Explanation 

TABLE  4  gives  explanation  for  those  communications  overheard  by  the  network  that 
were  in  excess  of  the  set  limitation  on  the  number  of  RTSs  for  the  experiment. 


B.  ARQ  FREQUENCY 

Figure  6.2  demonstrates  the  link  layer  ARQ  attempts/re-tries  that  occurred  during 
FBE-I,  23  June  2001.  Automatic  Repeat  Request  (negative  acknowledgement);  525 
ARQ  transmissions  occurred.  An  ARQ  transmission  is  sent  by  the  intended  receiver 
node  to  the  transmitter  node  originating  the  DATA  packet.  The  ARQ  transmission 
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indicates  to  the  transmitting  node  that  the  data  packet  was  not  received  at  the  intended 
recipient/destination  node,  or  that  it  was  received  with  uncorrectable  errors.  The  initial 
transmitting  node  would  then  re-transmit  the  DATA  packet.  The  node  issues  an  ARQ  re¬ 
try  after  a  certain  lapsed  time-frame;  however,  during  FBE-I,  a  maximum  number  of 
ARQ  transmission  attempts  were  set  at  3.  Once  3  attempts  were  completed,  the  data 
packet  was  programmed  to  stop  trying,  and  the  DATA  packet  would  be  dropped.  The 
figure  shows  that  the  majority  of  the  transmissions  were  successful  without  ever  having 
to  utilize  the  ARQ  process  (456  out  of  525).  46  after  the  first,  4  after  the  second,  and  3 
were  successful  after  the  third  ARQ  attempt. 

ARQ  (0  attempts)=  456 
ARQ  (1  attempt)=  46 
ARQ  (2  attempts)=  4 
ARQ  (3  attempts)=  3 
ARQ  (6  attempts)=  1 

Total:  456  +  46x  1+4x2  +  3x3  +  6x  1= 


456 

46 

4  3  0  0  1 

ARQ(0)  ARQ(l)  ARQ(2)  ARQ  (3)  ARQ  (4)  ARQ(5)  ARQ  (6) 

NUMBER  OF  ARQs 

Figure  6.2  ARQ  Usage  (Link  Layer) 
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456  +  46  +  8  +  9  +6  =  525 


519  out  of  525  were  successful  within  the  allotted  3  ARQ  attempts. 

The  figure  also  demonstrates  even  though  the  ARQ  limitation  was  set  at  3,  link 
number  266,  packet  number  140  established  6  ARQs  to  attempt  to  complete  its 
transmission  through  the  network.  The  reason  for  the  excess  number  of  ARQ  attempts 
was  caused  by  a  submarine  aspect  problem  during  the  attempted  transmission. 
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VII.  CONCLUSION 


This  thesis  presents  statistical  analysis  of  the  FBE-I  Seaweb  link-layer  and 
network- layer  performance  on  23  June  2001.  The  results  show  that  Seaweb  is  a  viable 
technology  for  internetworking  various  undersea,  surface,  and  airborne  resources. 

This  analysis  was  limited  to  observations  obtained  largely  from  gateway  GD 
operating  as  a  system  monitor.  The  inability  of  GD  to  monitor  some  traffic  caused  some 
holes  in  the  analysis.  This  could  be  remedied  through  the  implementation  of  a  distributed 
monitoring  capability,  where  each  node  logs  diagnostics  about  traffic  it  is  involved  in. 

Further  analysis  would  benefit  from  the  availability  of  a  Seaweb  simulator 
representing  the  network  layer  and  link  layer.  This  would  provide  a  design  tool  for 
studying  the  deterministic  and  probabilistic  nature  of  the  network.  It  would  also  assist  in 
defining  or  redefining  certain  operational  aspects  of  the  network  with  respect  to  its 
performance  measures  (i.e.  quality  of  service,  latency,  throughput,  and  reliability). 

This  thesis  demonstrates  that  the  Seaweb  network  technology  performed  reliably 
and  has  great  potential  for  transforming  the  nature  of  undersea  warfare.  Underwater 
sensor  fields  and  wireless  communication  network  will  most  likely  be  the  answer  to 
homeland  protection  and  power  projection  abroad  to  deter  hostile  actions  against  U.S. 
allies  and  interests. 
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